In standard programming of an industrial cell with a number of robots that are to work in a shared space, it is necessary to define instructions within the program of each robot in order for the robot to carry out in succession the following operations:                1. Request for booking for entry into the shared region (an output signal to the control unit)        2. Wait for consent from the control unit for entry into the shared region (an input signal to the robot from the control unit)        3. Presence within the shared region (an output signal)        4. Exit from the shared region        
The succession of these commands must be repeated on each individual part of program in which a so-called programming “interblock” is envisaged (corresponding to a working step in the shared region). Management of the policy that regulates the accesses to one or more shared regions is entrusted to the control unit (PLC), which assumes the task of governing the priority of the robots that can gain access to said regions. In a simple example of program in which only two robots share a common working area, the PLC, given a request for access from a robot R1, checks that there are no other pending requests from the robot R2 and that the robot R2 is not working in the shared region. If this is the case, access to the robot R1 is allowed. Likewise, it is possible to reformulate the policy for access of the robot R2. The aforesaid system of PLC accesses can be represented schematically as appears in the annexed FIG. 1.
The robot programs must, on their own part, be able to manage the input signals (for access) and output signals (for communicating to the PLC booking and presence or otherwise within the shared region) in such a way as to be able to manage the policy of access to and exit from the shared regions properly. An example of robot program is the following:
send(req_I2, ON)wait(cons_I2, ON)send(interf _I2, OFF)send(req_I2, OFF)MOVEFLY JOINT TO pnt0650x ADVANCEMOVEFLY JOINT TO pnt0150x ADVANCEMOVEFLY JOINT TO pnt0653x ADVANCEMOVE JOINT TO wp4661,WITH CONDITION [spot(1, 4661, 1, FALSE)],ENDMOVEMOVEFLY JOINT TO pnt0444x ADVANCEMOVEFLY JOINT TO pnt0443x ADVANCEMOVEFLY JOINT TO pnt0442x ADVANCEMOVE JOINT TO xtn0008XSend (interf_ I2, ON)
As may be seen, there is envisaged sending of the signal req_I2, which represents the request for access to the interblock region I2. Following upon this signal, the system remains waiting for the signal cons_I2 that must be sent by the PLC to enable access to the interblock region. Once the go-ahead has been obtained from the PLC, the robot sends the signal of occupation of the interference region interf_I2 and sends the booking signal req_I2 to zero. Finally, after carrying out the movements, the robot sends the signal of occupation of the interblock region interf_I2 to zero.
Given an architecture of the above sort, the main limits are as follows.
If the flow of the robot programs is modified, there is a high likelihood of setting the system in situations of incongruence; for example, if a robot is moved manually (in PROG) into a shared region, the PLC is not “warned” of its presence, and this may cause a generic malfunctioning of the system of interblocks, with the consequent probable impact between the robots.
The complexity of the robot programs is particularly high in so far as for each single interblock it is necessary to enter the instructions for booking, waiting, presence, and abandonment of the shared region. There is no real-time control of the position of the robot for identifying the presence thereof in a shared region; de-activation of the programs of movement of the robot implies that in programming there does not exist any type of control for preventing collisions between robots. The possible modification of the working programs of the robot necessarily implies a consistent modification of the instructions regarding the interblocks in each part of the program or programs.
A further limit regards the very frequent eventuality that the user might skip some instructions in the working program (a bypass that is prevalently made in the initial steps of programming, for testing the working programs of the robots) or else that the user might move the cursor erroneously within the program, skipping, for example, the operations of request for access or occupation of the interblock region. The object of the present invention is to overcome the aforesaid drawbacks.